Priority data transport service

ABSTRACT

Techniques, devices, and systems for implementing a Priority Data Transport Service (PDTS) are disclosed. The PDTS provides authorized devices and/or authorized users with on-demand, priority data transport (e.g., priority Internet access). For example, the PDTS allows authorized devices and/or authorized users to access the Internet, use mobile applications, and/or send and receive image data, video data, and text data in a prioritized manner, as compared to the regular (non-priority) Internet access that is provided to non-subscribers of the PDTS over commercial telecommunications networks. An authorized user may activate and deactivate the PDTS on demand. For instance, the PDTS may be activated during an emergency or crisis situation when networks may be congested, thereby providing the user with priority data transport (e.g., priority Internet access) in an emergency or crisis situation when a telecommunications network may be overloaded.

RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. Pat.Application No. 17/379,466, filed on Jul. 19, 2021, the entire contentsof which are incorporated herein by reference.

BACKGROUND

The United States government has a long-running PriorityTelecommunications Service (PTS) program to ensure the public safety andnational security and emergency preparedness (NS/EP) communicationscommunity has access to priority telecommunications and restorationservices to communicate under all circumstances. One PTS service calledthe Wireless Priority Service (WPS) allows a NS/EP user to use apre-authorized (or subscribed) device (e.g., a WPS phone) to gainprioritized processing of voice traffic, thereby increasing theprobability of call completion. For example, a user of a WPS phone candial a particular sequence of characters followed by the destinationnumber to make a WPS call, and this WPS call is treated with priorityover regular calls. Another PTS service called the Government EmergencyTelecommunications Service (GETS) is device-agnostic, which means that aNS/EP user can use any available phone to gain prioritized processing ofvoice traffic. For example, a NS/EP user who is in possession of apersonal identification number (PIN) that is usable to access the GETSmay borrow a bystander’s phone, dial a specific number, enter their PIN,and a subsequent call using the borrowed phone will be treated withpriority over regular calls. When the NS/EP user is finished with theGETS call, the phone returns to normal, unprioritized service. Yetanother PTS service called the Next Generation Network Priority Service(NGN-PS) enables NS/EP users to have priority voice, data, and videocommunications as the communications networks evolve. The Cybersecurityand Infrastructure Security Agency (CISA) is leading the development ofpriority services for voice over Internet Protocol (VoIP) based networksand will continue planning for data and video priority during futurebudget years. WPS-and/or GETS-like capabilities are likely to beprovided under the NGN-PS.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is set forth with reference to the accompanyingfigures, in which the left-most digit of a reference number identifiesthe figure in which the reference number first appears. The use of thesame reference numbers in different figures indicates similar oridentical items or features.

FIG. 1 illustrates an environment in which users may activate a prioritydata transport service (PDTS) using various techniques, according tovarious embodiments.

FIG. 2A is a diagram illustrating a user equipment (UE) that isregistered for multiple network slices, as well as the UE establishing aprotocol data unit (PDU) session over a first network slice of themultiple network slices while the PDTS is deactivated (or OFF), thefirst network slice providing transport of data sent from the UE duringthe PDU session without priority.

FIG. 2B is a diagram illustrating the registered UE of FIG. 2Aestablishing a PDU session over a second network slice of the multiplenetwork slices while the PDTS is activated (or ON), the second networkslice providing transport of data sent from the UE during the PDUsession with priority.

FIG. 3 illustrates a flowchart of an example process for activating, andsubsequently deactivating, the PDTS, according to various embodiments.

FIG. 4 illustrates a flowchart of an example process for activating, andsubsequently deactivating, the PDTS for a WPS UE, according to variousembodiments.

FIG. 5 illustrates a flowchart of an example process for activating, andsubsequently deactivating, the PDTS for any UE (e.g., a non-WPS UE),according to various embodiments.

FIGS. 6A-6C illustrate a flowchart of an example process to beimplemented by a network node(s) for activating the PDTS for a UE,according to various embodiments.

FIG. 7 is a block diagram of an example UE with logic toactivate/deactivate the PDTS, according to various embodiments.

FIG. 8 is a block diagram of an example network node(s) with logic toactivate/deactivate the PDTS for one or more UEs, according to variousembodiments.

DETAILED DESCRIPTION

Described herein are techniques, devices, and systems for implementing aPriority Data Transport Service (PDTS), including the activation anddeactivation thereof, to provide authorized devices and/or authorizedusers with on-demand, priority data transport (e.g., priority Internetaccess). For example, the PDTS allows authorized devices and/orauthorized users to access the Internet, use mobile applications, and/orsend and receive image data, video data, and text data in a prioritizedmanner, as compared to the regular (non-priority) Internet access thatis provided to non-subscribers of the PDTS over commercialtelecommunications networks. An authorized user may activate the PDTS ondemand, such as during an emergency or crisis situation when networksmay be congested, thereby providing the user with priority datatransport (e.g., priority Internet access) in an emergency or crisissituation when a telecommunications network may be overloaded.

The PDTS may be implemented using UE Route Selection Policy (URSP) rulesand network slicing. For example, a UE may initially register formultiple network slices. The multiple network slices may include a first(non-priority) network slice, and a second (priority) network slice thatis configured to provide higher-priority transport of data packetsduring PDU sessions than the first network slice. Upon registering forthe multiple network slices, the UE can then be used to activate thePDTS on-demand. When the PDTS is activated, the UE is updated with a setof URSP rules that cause the UE to send and receive data packets via thesecond (priority) network slice during a PDU session, thereby providingpriority data transport (e.g., Internet access) to the user of the UEduring the PDU session. To activate the PDTS, the user of the UE canprovide unique user input, such as by entering a specific uniformresource locator (URL) into a browser to navigate the browser to a PDTSportal, or by launching a PDTS application on the UE, among other waysof activating the PDTS. Based at least in part on the user inputreceived by the UE, the UE receives a new set of URSP rules, which, insome examples, may replace the existing URSP rules in local memory ofthe UE. The new set of URSP rules include, among other rules, a defaultrule that causes data traffic for a PDU session to be sent from the UEand received by the UE via the second (priority) network slice. In someexamples, the new set of URSP rules cause the UE to send and receivedata exclusively over a 3^(rd) generation partnership project (3GPP)core network, such as by sending data packets over the air (OTA) via agNodeB (gNB) to the a fifth generation (5G) New Radio (NR) core network.The new set of URSP rules received by the UE thereby prevent datapackets from being sent over a WiFi (e.g., a wireless (e.g., IEEE802.1x-based)) access point (AP) while the PDTS is activated.

After activating the PDTS, the user can deactivate the PDTS similarly byproviding unique user input, such as by entering the same, specific URLinto the browser to navigate the browser to the PDTS portal, or bylaunching the PDTS application on the UE, etc. Once the PDTS isdeactivated, the UE may revert to using the original URSP rules. Forexample, if the UE deleted the original URSP rules upon receiving thenew, second set of URSP rules, the URSP rules on the UE may be replacedagain, this time with the original URSP rules that were stored on the UEprior to activation of the PDTS. Thereafter, when a new PDU session isestablished, data traffic is routed, by default, according to theoriginal URSP rules, via the first (non-priority) network slice.

The techniques, devices, and systems described herein provide authorizeddevices and/or authorized users with prioritized data transport (e.g.,Internet access), which may be crucial in an emergency or crisissituation, such as by increasing the likelihood of emergency responseservices being provisioned to people in need of assistance, by helpingselect officials access information and/or transmit images, video, etc.with a service and/or with others, for example. The techniques, devices,and systems described herein improve traditional approaches to networkslicing and implementing URSP rules to support on-demand activation anddeactivation of the PDTS for PDU sessions established over atelecommunications network (e.g., 5G NR network). Furthermore, thetechniques, devices, and system described herein allow for expanding theexisting PTS programs capabilities beyond just voice by providingpriority data transport to wireless packets carrying non-voice data(e.g., video data, image data, text data, etc.). For example, the PDTScan provide authorized devices and/or authorized users with prioritizedaccess to public websites, agency-specific (or enterprise-specific)applications, and the like, in order to send and receive non-voice data(e.g., videos, images, text, etc.) with priority. In other words,whenever an authorized user would like to ensure that a PDU session issuccessfully established and remains uninterrupted, the user canactivate the PDTS so that a PDU session will be treated with priorityover regular PDU sessions of regular users. The techniques, devices, andsystems described herein also provide for a streamlined delivery of thePDTS to authorized NS/EP users, and a common way for wireless carriersto provide the PDTS to their NS/EP customers.

Moreover, the techniques, devices, and systems described herein ensurethat data traffic is carried with priority over a 3GPPtelecommunications core network (e.g., 5G NR core network) by preventingdata from being transmitted over WiFi. That is, when the PDTS isactivated for a UE, the UE is updated with a new set of URSP rules thatprevent the UE from bypassing the 3GPP 5G NR and 5G core network. Forexample, the new set of URSP rules received by the UE in response toactivation of the PDTS can control the routing of data packetsexclusively over bearers where priority service is supported, therebyensuring that, when the PDTS is activated, data traffic does not flowover WIFI. The techniques, devices, and systems described herein mayfurther allow one or more devices to conserve resources with respect toprocessing resources, memory resources, networking resources, powerresources, etc., in the various ways described herein. For example, byselectively providing authorized devices and/or authorized users withon-demand access to the PDTS, networking resources may be conserved forthose individuals who are authorized to receive priority Internet accessin a situation where the telecommunications network may be overloadedand congested, such as during an emergency or crisis situation.

An example process to be implemented by a UE can include registering fora first network slice and a second network slice, wherein the secondnetwork slice is configured to provide higher priority transport of datapackets during PDU sessions than the first network slice, receiving userinput to activate a PDTS, receiving, based at least in part on the userinput, a set of URSP rules and storing the set of URSP rules in memoryof the UE, and sending, based at least in part on a URSP rule of the setof URSP rules, one or more data packets during a PDU session via atleast one of: the second network slice, or a third network slice that isconfigured to provide higher priority transport of data packets duringPDU sessions than the first network slice.

An example process to be implemented by a network node(s) can includeregistering a UE for a first network slice and a second network slice,wherein the second network slice is configured to provide higherpriority transport of data packets during PDU sessions than the firstnetwork slice, receiving, from the UE, a PDU session establishmentrequest via the second network slice, sending, to the UE, a set of URSPrules to the UE, and routing one or more subsequent data packetsassociated with a PDU session involving the UE via at least one of: thesecond network slice, or a third network slice that is configured toprovide higher priority transport of data packets during PDU sessionsthan the first network slice.

Also disclosed herein are systems and devices comprising one or moreprocessors and one or more memories, as well as non-transitorycomputer-readable media storing computer-executable instructions that,when executed, by one or more processors perform various acts and/orprocesses disclosed herein.

FIG. 1 illustrates an environment 100 in which users may activate apriority data transport service (PDTS) using various techniques,according to various embodiments. The environment 100 may include afirst user equipment (UE) 102(1) used by a first user 104(1), and asecond UE 102(2) used by a second user 104(2). The first user 104(1) mayrepresent an authorized user of the WPS (or the NGN-PS with WPS-likecapabilities), and is sometimes referred to herein as a “WPS user104(1)” accordingly. Furthermore, the first UE 102(1) may represent anauthorized UE that is subscribed to the PDTS, and is sometimes referredto herein as a “WPS UE 102(1)” accordingly. Meanwhile, the second user104(2) may represent an authorized user of the GETS (or the NGN-PS withGETS-like capabilities), and is sometimes referred to herein as a “GETSuser 104(2)” accordingly. The second UE 102(2) may, therefore, representany UE, such as a UE that is not subscribed to the PDTS (e.g., a non-WPSUE). The users 104 may represent people who have received an account(e.g., user account, subscriber account, etc.) that provides them withaccess to the PDTS over commercial telecommunications networks. Forinstance, the users 104 may represent state, local, or tribal governmentNS/EP officials, individuals in the private sector who are authorized touse the PDTS, or the like.

In accordance with various embodiments described herein, the terms “userequipment (UE),” “wireless communication device,” “wireless device,”“communication device,” “mobile device,” “client device,” “electronicdevice,” and “device” may be used interchangeably herein to describe anyUE (e.g., the UEs 102) that is capable of transmitting/receiving datawirelessly using any suitable wireless communications/data technology,protocol, or standard, such as Global System for Mobile Communications(GSM), Time Division Multiple Access (TDMA), Universal MobileTelecommunications System (UMTS), Evolution-Data Optimized (EVDO), LongTerm Evolution (LTE), Advanced LTE (LTE+), Generic Access Network (GAN),Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA),Orthogonal Frequency Division Multiple Access (OFDM), General PacketRadio Service (GPRS), Enhanced Data GSM Environment (EDGE), AdvancedMobile Phone System (AMPS), High Speed Packet Access (HSPA), evolvedHSPA (HSPA+), Voice over IP (VoIP), Voice over LTE (VoLTE), Voice overNR (VoNR), IEEE 802.1x protocols, WiMAX, Wi-Fi, Data Over Cable ServiceInterface Specification (DOCSIS), digital subscriber line (DSL), and/orany future IP-based network technology or evolution of an existingIP-based network technology, including 5G NR networking protocols,and/or existing or legacy network technology, such as second generation(2G), third generation (3G), fourth generation (4G), includingcircuit-switched networking protocols and/or packet-switched networkingprotocols. The UEs 102 may be implemented as any suitable type ofcomputing device configured to communicate over a wireless network,including, without limitation, a mobile phone (e.g., a smartphone/handset), a tablet computer, a laptop computer, a portable digitalassistant (PDA), a wearable computer (e.g., electronic/smart glasses, asmart watch, fitness trackers, head-mounted display (HMD), etc.), anin-vehicle (e.g., in-car) computer, and/or any similar mobile device, aswell as situated computing devices including, without limitation, atelevision (smart television), set-top-box (STB), desktop computer, andthe like.

In general, the users 104 can utilize their UEs 102 to communicate withother computing devices of a telecommunications network, such as via acore network 106, as illustrated in FIG. 1 . The core network 106 ofFIG. 1 may represent an Internet Protocol Multimedia Subsystem (IMS)core network, sometimes referred to herein as “IMS core,” “IMS network,”“Core Network (CN),” or “IM CN Subsystem”. The IMS core is anarchitectural framework defined by the 3GPP for delivering InternetProtocol (IP) multimedia to a UE, such as the UEs 102. The IMS core canbe maintained and/or operated by one or more service providers, such asone or more wireless carriers (or “operators”), that provide IMS-basedservices to users (sometimes called “subscribers”) who are associatedwith UEs, such as the UEs 102. For example, a service provider may offermultimedia telephony services that allow a subscribed user to call ormessage other users via an IMS core using his/her UE. A user can alsoutilize an associated UE to receive, provide, or otherwise interact withvarious different IMS-based services by accessing computing devices ofan IMS core. In this manner, an operator of an IMS core may offer anytype ofIMS-based service, such as, telephony services, emergencyservices (e.g., E911), gaming services, instant messaging services,presence services, video conferencing services, social networking andsharing services, location-based services, push-to-talk services,texting services, real-time text (RTT) services, web browsing, and soon. In order to access these services, a UE 102 is configured to requestestablishment of a communication session. In the case of non-voiceservices, such as Internet services, texting services, and the like,such a communication session may comprise a PDU session.

The UEs 102 are each configured to utilize various access networks,including radio access networks (RANs) and/or radio access technologies(RATs), in order to access certain network nodes of the core network106. UEs that are 5G NR-compliant may be configured to communicate withheterogeneous cellular networks by employing radios that can communicateover 5G systems (or “5G networks”) as well as over legacy or predecessorsystems (or “legacy networks”) relative to 5G systems. Similarly, UEsthat are 4G LTE-compliant may be configured to communicate withinheterogeneous cellular networks by employing radios that can communicateover LTE systems (or “LTE networks”) as well as over legacy orpredecessor systems (or “legacy networks”) relative to 4G systems.Today’s legacy networks, such as 3G and 2G networks, may employcircuit-switching for voice communications, while 5G and 4G networksemploy packet-switching for both data and voice communications in anall-IP data transport technology. In general, 4G LTE-compliant UEs and5G NR-compliant UEs are configured to prefer attachment to correspondingnetworks, which offer relatively high data-rate throughput as comparedto available legacy or predecessor networks. In most UEs, a choice ofwhich protocol to employ depends primarily on what networks areavailable to the UE at the UE’s present geographic location.Furthermore, in instances where the preferred network (e.g., 4G, 5G,etc.) is unavailable or unusable for any reason, legacy networks, ifavailable, may be used as a fallback protocol, such as by using acircuit-switch fallback (CSFB) mechanism. The UEs 102 of FIG. 1 cancomprise a UE with such capabilities to allow for communication over anytype of telecommunications network. Accordingly, in the case of 5GNR-compliant UEs, the core network 106 may, in some examples, includenetwork nodes of a 5G system, such as a policy control function (PCF), asession management function (SMF), an access and mobility managementfunction (AMF), an authentication server function (AUSF), and the like.Accordingly, the UEs 102 may be configured to access such network nodesvia a gNodeB of an available 5G NR RAN.

FIG. 1 illustrates example techniques for activating a PDTS. In theexample of FIG. 1 , both of the users 104(1) and 104(2) are subscribedto the PDTS as subscribed users. The first UE 102(1) is also subscribedto the PDTS as a subscribed device. However, the second UE 102(2)represents a generic UE that is not subscribed to the PDTS. Each UE 102may perform an initial device registration procedure in order to accessthe 5G system, which may be included in the core network 106 depicted inFIG. 1 . If successful, a registered UE 102 that has completed theinitial device registration procedure will be able to establish a radiolink in order to transmit data to, and receive data from, particularnodes in the core network 106. The initial device registration proceduremay include, among other sub-procedures, requesting registration for oneor more network slices.

Network slicing is a feature of 5G networks. In 3GPP, a network slice isa logical end-to-end network that can be dynamically created. A givenUE, such as the UE 102(1), may access one or more network slices overthe same Access Network (e.g., over the same radio interface). Eachnetwork slice for which the UEs 102 are registered may providenetworking service with an agreed-upon Service-Level Agreement (SLA). Agiven network slice may be identified by a value of a Single NetworkSlice Selection Assistance Information (S-NSSAI) parameter that isassigned to the network slice. Accordingly, the UEs 102 can register forone or more network slices by including the value(s) of the S-NSSAIparameter(s) for the requested network slice(s) in the registrationrequest. In this case, each of the UEs 102 in FIG. 1 may register formultiple network slices including a first network slice and a secondnetwork slice. The first network slice may be associated with one ormore performance parameters (e.g., a Quality of Service (QoS) parameter)that provide regular, non-priority transport of data packets during PDUsessions. Meanwhile, the second network slice may be associated with oneor more performance parameters (e.g., a QoS parameter) that providehigher priority transport of data packets during PDU sessions than thefirst network slice. In some examples, the first network slice may be anenhanced Mobile Broadband (eMBB) network slice. However, the secondnetwork slice may differ for the respective UEs 102(1) and 102(2)depicted in FIG. 1 . For example, the WPS UE 102(1) may register for afirst, eMBB network slice and a second, PDTS network slice, while thegeneric UE 102(2) may register for the first, eMBB network slice and asecond, PDTS non-subscriber network slice. In other words, the genericUE 102(2) may not be authorized to register for and/or utilize the PDTSnetwork slice until the user 104(2) of the UE 102(2) successfullyauthenticates with the PDTS. Still, in either case, each UE 102registers for multiple network slices; one network slice that is anon-priority network slice, and another network slice that is a prioritynetwork slice.

In some examples, after the respective UEs 102 have registered formultiple network slices, the UEs 102 may establish respective PDUsessions to register for IMS-based services over the respective PDUsessions. For example, a UE 102 may identify a proxy call sessioncontrol function (P-CSCF) node of the core network 106 and send aregistration request via a gNB to an address of the identified P-CSCFnode. As used herein, a “request” is a message that is sent from a UE102 to a network node of the core network 106, and a “response” is amessage that is sent from a network node of the core network 106 to a UE102. This construct may be used when discussing communications that useany particular signaling protocol, Session Initiation Protocol (SIP)being one example protocol that can be used to send requests and receiveresponses. For example, SIP may be used by the UEs 102 for transmittingmessages to/from a network node of the core network 106. Accordingly, a“SIP request” is a message that is sent from a UE 102 to the corenetwork 106 using SIP protocol, and a “SIP response” is a message thatis sent from the core network 106 to a UE 102 using SIP protocol. SIP isa signaling protocol that can be used to establish, modify, andterminate multimedia sessions over packet networks, and to authenticateaccess to IMS-based services. Accordingly, during IMS registration, a UE102 may send a SIP request (e.g., a registration request) using the SIPREGISTER method as part of the initial procedures for registering forIMS-based services.

Additionally, or alternatively, after the respective UEs 102 haveregistered for multiple network slices, the users 104 can utilize theirUEs 102 to establish communication sessions. For example, the UEs 102can establish respective PDU sessions such that the UEs 102 may accessthe Internet via the core network 106, for example. Before activatingthe PDTS, each of the UEs 102 may establish a PDU session via the first(non-priority) network slice for which the UEs 102 previouslyregistered. At any time, either user 104 may activate (or “turn on”) thePDTS by providing unique user input via his/her UE 102. Example types ofuser input to activate the PDTS are depicted in FIG. 1 .

For example, the WPS user 104(1) may provide, and the WPS UE 102(1) mayreceive, user input that corresponds to launching an application(sometimes referred to herein as a client application, a mobileapplication, or the like). For example, FIG. 1 depicts an example userinterface (UI) 108(1) presented on a display of the UE 102(1) after theuser 104(1) has provided user input to launch a PDTS application (e.g.,by selecting an icon for the PDTS application on a touch screen of theUE 102(1)). At a time when the user 104(1) launches the PDTSapplication, the UE 102(1) may have stored, in local memory of the UE102(1), a first set of URSP rules. In general, URSP rules may govern howa UE 102 behaves in terms of routing outgoing traffic. In the presentdisclosure, the first set of URSP rules stored in memory of the first UE102(1) at a time when the user 104(1) launches the PDTS application mayinclude a default URSP rule that causes the UE 102(1) to send datapackets during a PDU session via the first (non-priority) network slice.In other words, the default URSP rule in the first set of URSP rulescauses the UE 102(1) to direct traffic (e.g., all traffic) to the firstnetwork slice, such as an eMBB network slice. The first set of URSPrules may further include a URSP rule at the highest precedence withS-NSSAI_(PDTS), and, in some examples, a specific data network name(DNN)_(PDTS) and perhaps other parameters and traffic descriptionmatching an app identifier (ID) for the PDTS application. Accordingly,when the user 104(1) launches the PDTS application to activate the PDTS,logic of the UE 102(1) determines that a URSP rule of the first set ofURSP rules matches the app ID of the PDTS application, which indicatesthat the user 104(1) would like to activate the PDTS and the packetmatching the highest precedence URSP rule is directed over theS-NSSAI_(PDTS) slice. As depicted in FIG. 1 , the user 104(1) may selecta button 110(1) (e.g., a “Turn ON” button, icon, element, etc.) in orderto activate the PDTS, which may be additional user input in addition tothe user input to launch the PDTS application. In response to the user104(1) launching the PDTS application and the UE 102(1) determining thatthe URSP rule matches the app ID of the PDTS application (and, in someexamples, after the UE 102(1) is authenticated as a WPS subscriber), theUE 102(1) may send a PDU session establishment request for the second(priority) network slice (e.g., S-NSSAI_(PDTS)). In some examples, thePDU session establishment request may include a specific DNN_(PDTS) andperhaps other parameters. In some examples, the UE 102(1) mayre-register for IMS-based services (e.g., if previously registered forthe IMS-based services) over the new priority PDU session in order toreceive priority for the IMS-based services. Furthermore, a UEconfiguration update may be initiated for the UE 102(1), wherein the UE102(1) receives a second set of URSP rules 112(1) and stores the secondset of URSP rules 112(1) in the memory of the UE 102(1). In someexamples, the UE 102(1) deletes the existing, first set of URSP rules ata time of receiving the second set of URSP rules 112(1) in order toreplace the first set of URSP rules in the memory of the UE 102(1). Inother examples, the original, first set of URSP rules may be maintained(or kept) in the memory of the UE 102(1), and the UE 102(1) may use apointer to reference the new, second set of URSP rules 112(1) goingforward. The second set of URSP rules 112(1) received by the UE 102(1)during the UE configuration update may include a default URSP rule thatcauses the UE 102(1) to send data packets (e.g., all data packets)during a PDU session via the second (priority) network slice. In otherwords, the default URSP rule in the second set of URSP rules 112(1)causes the UE 102(1) to direct traffic (e.g., all traffic) to the secondnetwork slice, such as a PDTS network slice. Since the second (priority)network slice provides higher priority transport of data packets duringPDU sessions than the first (non-priority) network slice (e.g., byvirtue of a different QoS parameter(s) and/or other performanceparameters associated with the second network slice), the second set ofURSP rules 112(1) will cause the UE 102(1) to send data packets withpriority via the second (priority) network slice during any PDU sessionthat is established after the PDTS has been activated.

FIG. 1 also depicts another example technique for activating the PDTSwith respect to the GETS user 104(2). It is to be appreciated that thisother example technique may be utilized with the WPS user 104(1) aswell. In the example of FIG. 1 , the GETS user 104(2) may provide, andthe generic UE 102(2) may receive, user input that corresponds tonavigating a browser to a web site. For example, FIG. 1 depicts anexample user interface (UI) 108(2) presented on a display of the UE102(2) after the user 104(2) has provided user input to enter a specificUniform Resource Locator (URL) 114 into a browser, the URL causing thebrowser to navigate to a PDTS portal. At a time when the user 104(2)navigates the browser to the PDTS portal, the UE 102(2) may have stored,in local memory of the UE 102(2), a first set of URSP rules that governshow the UE 102(2) behaves in terms of routing outgoing traffic. Forexample, the first set of URSP rules stored in memory of the second UE102(2) at a time when the user 104(2) navigates the browser to the PDTSportal may include a default URSP rule that causes the UE 102(2) to senddata packets during a PDU session via the first (non-priority) networkslice. In other words, the default URSP rule in the first set of URSPrules causes the UE 102(2) to direct all traffic to the first networkslice, such as an eMBB network slice. The first set of URSP rules mayfurther include a URSP rules at the highest precedence withS-NSSAI_(PDTS-nonsub), and, in some examples, a specificDNN_(PDTS-nonsub) and perhaps other parameters and traffic descriptionmatching an ID of the site to which the user 104(2) navigated thebrowser. The ID of the site may be in the form of an address or a fullyqualified domain name (FQDN) of the PDTS portal. Accordingly, when theuser 104(2) navigates the browser to the PDTS portal to activate thePDTS, logic of the UE 102(2) determines that a URSP rule of the firstset of URSP rules specifies the site ID of the PDTS portal, whichindicates that the user 104(2) would like to activate the PDTS. Inresponse to the user 104(2) navigating the browser to the PDTS portaland the UE 102(2) determining that the URSP rule specifies the site IDof the PDTS portal, the UE 102(2) may send a PDU session establishmentrequest for the second (PDTS non-subscriber) network slice (e.g.,S-NSSAI_(PDTS-nonsub)). In some examples, the PDU session establishmentrequest may include a specific DNN_(PDTS-nonsub) and perhaps otherparameters. In some examples, the act of sending a HTTP GET to thematching URL initiates the PDU session establishment request. Asdepicted in FIG. 1 , the user 104(2) may enter credentials 116 (e.g., ausername and/or a password) via the site and may select a button 110(2)(e.g., a “LOGIN” button, icon, element, etc.) to activate the PDTS,which may be additional user input in addition to the user input tonavigate the browser to the PDTS portal. In this case, because the UE102(2) is generic and is not already subscribed to the PDTS, thecredentials 116 entered by the GETS user 104(2) via the PDTS portal areprocessed to authenticate the GETS user 104(2), which ensures that theuser 104(2) is subscribed to the PDTS. In response, a UE configurationupdate may be initiated for the UE 102(2), wherein the UE 102(2)receives a second set of URSP rules 112(2) and stores the second set ofURSP rules 112(2) in the memory of the UE 102(2). Again, in someexamples the second set of URSP rules 112(1) may replace the first setof URSP rules in the memory of the UE 102(2) (e.g., the UE 102(2) maydelete the first set of URSP rules from the memory of the UE 102(2) at atime of receiving the second set of URSP rules 112(2)). In otherexamples, the original, first set of URSP rules remain stored in thememory of the UE 102(2) despite receiving the second set of URSP rules112(2) and a pointer or a similar mechanism may be utilized to determinewhich set of rules to utilize for controlling traffic sent from the UE102(2). The second set of URSP rules 112(2) received by the UE 102(2)during the UE configuration update may include a default URSP rule thatcauses the UE 102(2) to send data packets (e.g., all data packets)during a PDU session via a (priority) network slice, such as a PDTSnetwork slice. In the case of the GETS user 104(2) and the generic UE102(2), the UE 102(2) may have initially registered for a second(priority) network slice, such as a PDTS non-subscriber network slicethat is used during a PDU session to authenticate the GETS user 104(2)via the PDTS portal. Subsequently, after the GETS user 104(2) isauthenticated, one or more network nodes in the core network 106 mayauthorize the UE 102(2) to route traffic via a third (priority) networkslice, such as the PDTS network slice. In other words, the core networktransitions the UE 102(2) to the third (priority) network slice aftersuccessfully authenticating the GETS user 104(2), even though the UE102(2) itself does not have a subscription to the PDTS and, therefore,did not previously register for the third (priority) network slice forwhich subscribed UEs can register. In any case, the default URSP rule inthe second set of URSP rules 112(2) causes the UE 102(2) to direct alltraffic to the third (priority) network slice, such as the PDTS networkslice. Since the third (priority) network slice provides higher prioritytransport of data packets during PDU sessions than the first(non-priority) network slice (e.g., by virtue of a different QoSparameter(s) and/or other performance parameters associated with thethird (priority) network slice), the second set of URSP rules 112(2)will cause the UE 102(2) to send data packets with priority via thethird (priority) network slice during any PDU session that isestablished after the PDTS has been activated.

FIG. 2A is a diagram illustrating a UE 102, which may represent eitherthe UE 102(1) or the UE 102(2) depicted in FIG. 1 . As described above,during an initial attach procedure, a UE 102 can register for multiplenetwork slices 200 by including the respective values of the S-NSSAIparameter for the requested network slices 200 in the registrationrequest. In the example of FIG. 2A, the UE 102 may register for a firstnetwork slice 200(A), such as an eMBB network slice, which may beassociated with one or more performance parameters (e.g., a QoSparameter(s)) that provide regular, non-priority transport of datapackets during PDU sessions. In the case of a WPS UE 102(1), the UE 102may also register for a second network slice 200(B) in the form of aPDTS network slice. This second network slice 200(B) may be associatedwith one or more performance parameters (e.g., a QoS parameter(s)) thatprovide higher priority transport of data packets during PDU sessionsthan the first network slice 200(A). In the case of a generic UE 102(2),the UE 102 may register for a second network slice in the form of a PDTSnon-subscriber network slice (not shown in FIG. 2A), and, if the GETSuser 104(2) of the generic UE 102(2) is authenticated during an attemptto activate the PDTS, the UE 102(2) may ultimately utilize the secondnetwork slice 200(B), such as the PDTS network slice, during a PDUsession. Regardless of the type of UE 102, the UE 102 registers formultiple network slices 200.

FIG. 2A illustrates a scenario where the PDTS is “OFF” (or deactivated).Accordingly, while the PDTS is OFF, when the user 104 of the UE 102accesses the Internet, a PDU session 202(A) is established such that theUE 102 sends one or more data packets to the core network 106 during thePDU session 202(A) via the first network slice 200(A) without priority.This control over the routing of outgoing data packets is provided bythe existing set of URSP rules stored in local memory of the UE 102.Accordingly, FIG. 2A may illustrate a PDU session 202(A) that isestablished on behalf of the UE 102 prior to the UE 102 having receivedthe user input to activate the PDTS, as illustrated in FIG. 1 , whichmeans that a first set of URSP rules governs how the UE 102 behaves interms of routing outgoing traffic; namely, by routing network trafficvia the first network slice 200(A).

FIG. 2B illustrates a scenario where the PDTS is “ON” (or activated).Accordingly, while the PDTS is ON, when the user 104 of the UE 102accesses the Internet, a PDU session 202(B) is established such that theUE 102 sends one or more data packets to the core network 106 during thePDU session 202(B) via the second network slice 200(B) with priority.This control over the routing of outgoing data packets is provided bythe received set of URSP rules 112 stored in local memory of the UE 102.Accordingly, FIG. 2B may illustrate a PDU session 202(B) that isestablished on behalf of the UE 102 after the UE 102 has received theuser input to activate the PDTS, as illustrated in FIG. 1 , which meansthat a second set of URSP rules 112 governs how the UE 102 behaves interms of routing outgoing traffic; namely, by routing network trafficvia the second network slice 200(B). This also assumes that the UE 102and/or the user 104 is authenticated with respect to the PDTS as asubscribed device and/or a subscribed user, respectively. The user 104of the UE 102 is able to toggle the PDTS ON and OFF by providing theuser input illustrated by way of example and not limitation in FIG. 1(e.g., by launching the PDTS app or by navigating a browser to a sitefor the PDTS portal).

The processes described in this disclosure may be implemented by thearchitectures described herein, or by other architectures. Theseprocesses are illustrated as a collection of blocks in a logical flowgraph. Some of the blocks represent operations that can be implementedin hardware, software, or a combination thereof. In the context ofsoftware, the blocks represent computer-executable instructions storedon one or more computer-readable storage media that, when executed byone or more processors, perform the recited operations. Generally,computer-executable instructions include routines, programs, objects,components, data structures, and the like that perform particularfunctions or implement particular abstract data types. The order inwhich the operations are described is not intended to be construed as alimitation, and any number of the described blocks can be combined inany order or in parallel to implement the processes. It is understoodthat the following processes may be implemented on other architecturesas well.

FIG. 3 illustrates a flowchart of an example process 300 for activating,and subsequently deactivating, the PDTS, according to variousembodiments. The process 300 is described with reference to the previousfigures.

At 302, a UE 102 may register for multiple network slices 200. Themultiple network slices 200 may include a first network slice 200(A) anda second network slice (e.g., 200(B)). The second network slice isconfigured to provide higher priority transport of data packets duringPDU sessions than the first network slice 200(A). For example, the firstnetwork slice 200(A) may be an eMBB network slice. In an example wherethe UE 102 is a WPS UE 102(1) that is subscribed to the PDTS, the secondnetwork slice 200(B) for which the UE 102 registers at block 302 may bea PDTS network slice. In an example where the UE 102 is a generic UE102(2) that is not subscribed to the PDTS, the second network slice forwhich the UE 102 registers at block 302 may be a PDTS non-subscribernetwork slice. In an illustrative example, if the UE 102 is a WPS UE102(1), the UE 102 may send a registration request at block 302 with therequested NSSAI: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)}. Alternatively, if theUE 102 is a generic UE 102(1), the UE 102 may send a registrationrequest at block 302 with the requested NSSAI: {S-NSSAI_(PDTS-nonsub),S-NSSAI_(eMBB)}.

At 304, the UE 102 may determine whether the user 104 has requested toactivate the PDTS. For example, at sub-block 306, the UE 102 maydetermine whether it has received user input to activate the PDTS. In anillustrative example, at sub-block 308, the user input received by theUE 102 may correspond to at least one of navigating a browser to a site(e.g., the URL 114 of the PDTS portal depicted in FIG. 1 ) or launchingan application (e.g., the PDTS application depicted in FIG. 1 ), and, atsub-block 310, the UE 102 may determine that a URSP rule of an existing(first) set of URSP rules stored in memory of the UE 102 specifies an IDof at least one of the site or the application.

If no such user input is received at block 304, the process 300 mayfollow the NO route from block 304 to block 312 where, during a PDUsession 202(A), the UE 102 may send, based at least in part on a defaultURSP rule of the existing (first) set of URSP rules stored in the memoryof the UE 102, one or more data packets via the first (non-priority)network slice 200(A), and the process 300 may return to block 304 tocontinue monitoring for user-activation of the PDTS. If, at block 304,the UE 102 receives user input to activate the PDTS, the UE 102 may senda PDU session establishment request for a priority network slice, suchas S-NSSAI_(PDTS) or S-NSSAI_(PDTS-nonsub), and the process 300 mayfollow the YES route from block 304 to block 314.

At 314, the UE 102 may receive, based at least in part on the user inputreceived at block 306 and based at least in part on the PDU sessionestablishment request sent by the UE 102 for the priority network slice,a second set of URSP rules 112 (e.g., to replace the first set of URSPrules in the memory of the UE 102). The second set of URSP rules 112 mayinclude a default URSP rule that causes the UE 102 to send data packetsduring a PDU session via a priority network slice, such as the PDTSnetwork slice. In the case of a WPS UE 102(1), the UE 102(1) alreadyregistered for this PDTS network slice 200(B) at block 302. In the caseof a generic UE 102(2), the UE 102(2) registered for the PDTSnon-subscriber network slice at block 302, and subsequently, uponsuccessful authentication of the GETS user 104(2) of the UE 102(2), theUE 102(2) may be authorized (e.g., through backend procedures) to senddata packets via a third (PDTS) network slice 200(B).

At 316, the UE 102 may determine whether the user 104 has requested todeactivate the PDTS. For example, at sub-block 306, the UE 102 maydetermine whether it has received user input to deactivate the PDTS. TheUE 102 may monitor for the same, or similar, type of user input as itdid for activating the PDTS. For instance, at sub-block 308, the userinput received by the UE 102 may correspond to at least one ofnavigating a browser to a site (e.g., the URL 114 of the PDTS portaldepicted in FIG. 1 ) or launching an application (e.g., the PDTSapplication depicted in FIG. 1 ), and, at sub-block 310, the UE 102 maydetermine that a URSP rule of the second set of URSP rules 112 receivedby the UE 102 at block 314 specifies an ID of at least one of the siteor the application.

If no such user input is received at block 316, the process 300 mayfollow the NO route from block 316 to block 318 where, during a PDUsession 202(B), the UE 102 may send, based at least in part on a defaultURSP rule of the second set of URSP rules 112 stored in the memory ofthe UE 102, one or more data packets via a priority network slice200(B), and the process 300 may return to block 316 to continuemonitoring for user-deactivation of the PDTS. Again, in an example wherethe UE 102 represents a WPS UE 102(1), the priority network slice 200(B)that is used for the PDU session 202(B) at block 318 may correspond tothe second network slice 200(B) that the UE 102(1) registered for atblock 302. In an example where the UE 102 represents a generic UE102(2), the UE 102(2) may not have registered for this priority networkslice 200(B) at block 302. Instead, the UE 102(2) may have registeredfor a second or intermediate (PDTS non-subscriber) network slice atblock 302, and the UE 102(2) may have been authorized to use a third(PDTS) network slice 200(B) post registration, such as uponauthentication of the GETS user 104(2) of the UE 102(2) following block304. As shown by sub-block 320, the default URSP rule of the second setof URSP rules 112 received by the UE 102 may prevent data packets frombeing sent over Wi-Fi during the PDU session 202(B). If, at block 316,the UE 102 receives user input to deactivate the PDTS, the UE 102 maysend a PDU session establishment request for sliceS-NSSAI_(PDTS-turn-off), and the process 300 may follow the YES routefrom block 316 to block 322.

At 322, the UE 102 may receive, based at least in part on the user inputreceived at block 316, and based at least in part on the PDU sessionestablishment request sent by the UE 102 for sliceS-NSSAI_(PDTS-turn-off), the original (first) set of URSP rules (e.g.,to replace the second set of URSP rules 112 in the memory of the UE102). If the original (first) set of URSP rules were retained in thememory of the UE 102, however, the UE 102 may not receive any new URSPrules, but may change a pointer to reference the original (first) set ofURSP rules so that the original (first) set of URSP rules may beutilized going forward. The original (first) set of URSP rules mayinclude the default URSP rule that causes the UE 102 to send datapackets during a PDU session 202(A) via the first network slice 200(A),such as the eMBB network slice. Accordingly, the process 300 may returnto block 304 from block 322, and, if the user 104 has not activated thePDTS, and if the user 104 accesses the Internet, the UE 102 may, atblock 312, send, based at least in part on the default URSP rule of theoriginal (first) set of URSP rules stored in the memory of the UE 102,one or more data packets during a PDU session 202(A) via the first(non-priority) network slice 200(A). In this manner, the user 104 maytoggle the PDTS ON and OFF by iterating blocks of the process 300,thereby providing the user 104 with on-demand priority access to theInternet via a core network 106.

FIG. 4 illustrates a flowchart of an example process 400 for activating,and subsequently deactivating, the PDTS for a WPS UE 102(1). The WPS UE102(1) is already subscribed to the PDTS. For example, a SubscriberIdentity Module (SIM) card of the WPS UE 102(1) may be subscribed to afirst (eMBB) network slice 200(A) and to a second (PDTS) network slice200(B). Implementation of the process 400 assumes that (i) the UE’s 102subscription authentication (5G primary authentication) with the PDTS isallowed and/or (ii) using the 3GPP-defined secondary authentication viaan authentication, authorization and accounting (AAA) server outside the3GPP architecture is sufficient to establish PDTS authentication andauthorization. The process 400 is described with reference to theprevious figures.

At 402, the UE 102(1) may register with the core network 106 and requestmultiple network slices 200, such as a first (eMBB) network slice 200(A)and a second (PDTS) network slice 200(B), the second (PDTS) networkslice 200(B) being usable by UEs 102 that are subscribed to the PDTS toactivate and use the PDTS. The second (PDTS) network slice 200(B) isconfigured to provide higher priority transport of data packets duringPDU sessions than the first (eMBB) network slice 200(A). In anillustrative example, the UE 102(1), at block 402, may include in therequested NSSAI: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)}. A network node(s) mayconfirm that the UE’s 102(1) subscription has PDTS slice support, and,if so, may return, to the UE 102(1), an Allowed NSSAI set that includesthe PDTS network slice 200(B) and other network slices. For example,Allowed NSSAI may include: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)}. Thisconfirmation obtained by the network node(s) provides a first levelcheck for PDTS service. The UE 102(1) may be considered “registered” forthe multiple network slices 200 at block 402, but neither network slice200 is activated until a PDU session is established.

At 404, the UE 102(1) may send (and receive) one or more data packetsduring a PDU session 202(A) via the first (eMBB) network slice 200(A).By default, the UE 102(1) may have configured (e.g., stored in localmemory of the UE 102(1)) a set of URSP rules that may include, withoutlimitation, a default rule that directs traffic (e.g., all traffic) tothe first (eMBB) network slice 200(A), and a URSP rule at the highestprecedence with S-NSSAI_(PDTS), and optionally, a specific DNN_(PDTS)and perhaps other parameters and traffic description matching: (i) thePDTS portal address or FQDN, or (ii) an app ID for a PDTS app on the UE102(1). Accordingly, based on the default URSP rule, whenever the user104(1) provides user input to the UE 102(1) causing the UE 102(1) tosend data, the UE 102(1) establishes a PDU session 202(A) usingS-NSSAI_(eMBB) for regular Internet access. This might include other PDUsession parameters such as DNN_(eMBB). Internet traffic (e.g., allInternet traffic) runs over the PDU session 202(A) using the first(eMBB) network slice 200(A) (i.e., S-NSSAI_(eMBB)). The UE 102(1) mightalso have other PDU sessions 202 for other uses.

At 406, the UE 102(1) may receive user input to activate the PDTS. Insome examples, the user input received at block 406 may correspond tonavigating a browser to a site (e.g., the user entering a URL 114 of thePDTS portal into a web browser, as depicted in FIG. 1 ). In someexamples, the user input received at block 406 may correspond tolaunching an application (e.g., the PDTS app depicted in FIG. 1 ).

At 408, the UE 102(1) may determine that a URSP rule of the existing(first) set of URSP rules specifies an ID (e.g., an address, FQDN, etc.)of the site to which the user 104(1) pointed the browser, or an ID(e.g., app ID) of the application launched by the user 104(1). This IDmatch at block 408 may indicate that the user 104(1) wishes to activatethe PDTS on demand.

At 410, the URSP rule that specifies the ID of the site or the app atblock 408 may trigger the UE 102(1) to send a PDU session establishmentrequest for the second (PDTS) network slice 200(B) (e.g.,S-NSSAI_(PDTS)). In some examples, the PDU session establishment requestmay include a specific DNN_(PDTS) and perhaps other parameters. Thesecond (PDTS) network slice 200(B) is a priority network slice. On thenetwork side, in response to the UE 102(1) sending the PDU sessionestablishment request, an AMF may select an appropriate SMF for this newpriority PDU session. The selected SMF may perform a PDU sessionestablishment by contacting the PCF for authorization. The contacted PCFmay instruct traffic (e.g., all traffic) for this PDU session to betreated with higher priority compared to regular Internet access,thereby reducing the risk of pre-emption during a period of trafficcongestion. The PCF supports adjusting QoS parameters for priority andallocation and retention priority (ARP), as per standards for prioritydata service.

At 412, the UE 102(1) may send credentials for authenticating with thePDTS. The authenticating referenced at block 412 is sometimes referredto herein as “secondary slice authentication,” and it is optional for aWPS UE 102(1). Secondary slice authentication may run extensibleauthentication protocol (EAP) between the UE 102(1) and an AAA server,as per standard. The AAA server may be operated by the mobile operatoron behalf of an authenticating agency, or the AAA server may be operatedby the authenticating agency and may perform an authentication dedicatedto the PDTS. This secondary AAA server provides an additional check thatthe UE 102(1) identity is valid and authorized for the PDTS through aset of credentials dedicated to the PDTS that are already provisioned onthe UE 102(1). Accordingly, these credentials may be sent by the UE102(1) at block 412 as part of this secondary slice authentication.

At 414, the PCF may initiate a UE configuration update to replace theexisting URSP rules in the UE 102(1) with a new (second) set of URSPrules 112(1), and the UE 102(1) may, therefore, receive the second setof URSP rules 112(1) to replace the existing (first) set of URSP rulesin the memory of the UE 102(1). The second set of URSP rules 112(1) mayinclude a (default) URSP rule that causes the UE 102(1) to send datapackets during a PDU session 202(B) via the second (PDTS) network slice200(B). For example, the (default) URSP rule may direct traffic (e.g.,all traffic) to the second (PDTS) network slice 200(B) and PDU session202(B). This may include preferred access set to 5G, which prevents dataover WiFi. For example, the (default) URSP rule of the second set ofURSP rules 112(1) may prevent data packets from being sent over Wi-Fiduring the PDU session 202(B). The second set of URSP rules 112(1) mayfurther include URSP rule at the highest precedence withS-NSSAI_(PDTS-turn-off), and optionally, a specific DNN_(PDTS-turn-off)and perhaps other parameters and traffic description matching: (i) thePDTS portal address or FQDN, or (ii) an app ID for a PDTS app on the UE102(1). In some examples, the first PDU session 202(A) may be maintained(e.g., with no traffic). In other examples, the first PDU session 202(A)may be torn down.

At 416, the UE 102(1) may send (and receive) one or more data packetsduring a PDU session 202(B) via the second (PDTS) network slice 200(B).That is, if the user 104(1) provides user input to access the Internet,for example, the UE 102(1) may utilize the second (PDTS) network slice200(B) based on the (default) URSP rule of the second set of URSP rules112(1) received by the UE 102(1) at block 414. Accordingly, Internettraffic (e.g., all Internet traffic) runs over the PDU session 202(B)using the second (PDTS) network slice 200(B) (e.g., sliceS-NSSAI_(PDTS)). The settings of this PDU session 202(B) may be suchthat traffic (e.g., all traffic) is sent over a QoS enabled flow withhigh priority across both the RAN network and the core network 106.

At 418, the UE 102(1) may receive second user input to deactivate thePDTS. In some examples, the user input received at block 418 maycorrespond to navigating a browser to a site (e.g., the user enteringthe URL 114 of the PDTS portal into a web browser). In some examples,the user input received at block 418 may correspond to launching anapplication (e.g., the PDTS app depicted in FIG. 1 ).

At 420, the UE 102(1) may determine that a URSP rule of the received(second) set of URSP rules 112(1) specifies an ID (e.g., an address,FQDN, etc.) of the site to which the user 104(1) pointed the browser, oran ID (e.g., app ID) of the application launched by the user 104(1).This ID match at block 420 may indicate that the user 104(1) wishes todeactivate the PDTS on demand.

At 422, the URSP rule (of the second set of URSP rules 112(1)) at thehighest precedence with S-NSSAI_(PDTS-turn-off) may trigger the UE102(1) to send a PDU session establishment request for sliceS-NSSAI_(PDTS-turn-off) with optionally, a specific DNN_(PDTS-turn-)_(off) and perhaps other parameters. The network slice forS-NSSAI_(PDTS-turn-off) may be functionally equivalent to the second(PDTS) network slice 200(B) (e.g., S-NSSAI_(PDTS)), but the networkslice for S-NSSAI_(PDTS-turn-off) may be associated with a differentS-NSSAI value than the second (PDTS) network slice 200(B). On thenetwork side, the PDU session establishment request sent at block 422may trigger the AMF to select the same SMF for this new PDU session200(A) as the current SMF. The SMF may perform a PDU sessionestablishment by contacting the PCF for authorization. The PCF mayapprove the PDU session establishment (to allow some user interaction atthe portal, such as a logoff confirmation). However, based on thePDTS-turn-off session slice, the PCF may initiate a UE configurationupdate to replace the existing (second) set of URSP rules 112(1) in theUE 102(1) with the original (first) set of URSP rules before PDTSservice activation.

Accordingly, at 424, based on the UE configuration update initiated bythe PCF, the UE 102(1) may receive the original (first) set of URSPrules to replace the second set of URSP rules 112(1) in the memory ofthe UE 102(1). As shown in FIG. 4 , the process 400 may return to block404 following block 424 to iterate blocks 404-424 as the user 104(1)toggles the PDTS ON and OFF, in an on demand fashion. In other words,following block 424, the UE 102(1) may, at block 404, send (and receive)one or more data packets during a PDU session 202(A) via the first(eMBB) network slice 200(A) (e.g., S-NSSAI_(eMBB)). That is, if the user104(1) provides user input to access the Internet, for example, the UE102(1) may utilize the first (eMBB) network slice 200(A) based on the(default) URSP rule of the original (first) set of URSP rules receivedby the UE 102(1) at block 424. For example, the (default) URSP rule ofthe original (first) set of URSP rules may trigger the UE 102(1) to senda PDU session establishment request for the first (eMBB) network slice200(A) (e.g., S-NSSAI_(eMBB)) for regular Internet access per theupdated URSP rules, where Internet traffic (e.g., all Internet traffic)runs over the PDU session 202(A) using the first (eMBB) network slice200(A) (e.g., S-NSSAI_(eMBB)). If the previous PDU session 202(A) wasnot torn down, the UE 102(1) may send traffic over the first (eMBB)network slice 200(A), and the UE 102(1) may refrain from establishing anew PDU session, in this example. The PCF may provide the SMF with theoriginal set of policy and charging control (PCC) rules for various QoSflows to be used by the UE 102(1) for non-priority services. It is to beappreciated, however, that the UE 102(1) may have other PDU sessions 202for other uses. Furthermore, any traffic routing instructions for thesePDU sessions 202 may be restored to their original state before the PDTSactivation.

FIG. 5 illustrates a flowchart of an example process 500 for activating,and subsequently deactivating, the PDTS for any UE 102 (e.g., a non-WPSUE 102(2)). The non-WPS UE 102(2) is not subscribed to the PDTS.Implementation of the process 500 assumes that any UE 102 has thepotential to activate the PDTS, but that UEs 102 are not allowed toactivate the PDTS in instances where users 104(2) of the UEs 102 cannotbe authorized through a web service/web server. The process 500 supportsthe GETS, where a PDTS user can use or borrow any UE 102 to activate anduse the PDTS (including their own UE 102). The process 500 is describedwith reference to the previous figures.

At 502, the UE 102(2) may register with the core network 106 and requestmultiple network slices 200, such as a first (eMBB) network slice 200(A)and a second (PDTS non-subscriber) network slice, the second (PDTSnon-subscriber) network slice being usable by UEs 102 that are notsubscribed to the PDTS to activate the PDTS. The second (PDTSnon-subscriber) network slice is configured to provide higher prioritytransport of data packets during PDU sessions than the first (eMBB)network slice 200(A). In an illustrative example, the UE 102(2), atblock 502, may include in the requested NSSAI: {S-NSSAI_(PDTS-nonsub),S-NSSAI_(eMBB)}. The non-WPS (or PDTS non-subscriber) UE 102(2) isallowed to register for network slice S-NSSAI_(PDTS-nonsub), but the UE102(2) may not be able to register for network slice S-NSSAI_(PDTS)because it does not have a PDTS subscription. The UE 102(2) may beconsidered “registered” for the multiple network slices 200 at block502, but neither network slice 200 is activated until a PDU session isestablished.

At 504, the UE 102(2) may send (and receive) one or more data packetsduring a PDU session 202(A) via the first (eMBB) network slice 200(A).By default, the UE 102(2) may have configured (e.g., stored in localmemory of the UE 102(2)) a set of URSP rules that may include, withoutlimitation, a default rule that directs traffic (e.g., all traffic) tothe first (eMBB) network slice 200(A), and a URSP rule at the highestprecedence with S-NSSAI_(PDTS-nonsub), and optionally, a specificDNN_(PDTS-nonsub) and perhaps other parameters and traffic descriptionmatching the PDTS portal address or FQDN. Accordingly, based on thedefault URSP rule, whenever the user 104(2) provides user input to theUE 102(2) causing the UE 102(2) to send data, the UE 102(2) establishesa PDU session 202(A) using S-NSSAI_(eMBB) for regular Internet access.This might include other PDU session parameters such as DNN_(eMBB).Internet traffic (e.g., all Internet traffic) runs over the PDU session202(A) using the first (eMBB) network slice 200(A) (i.e.,S-NSSAI_(eMBB)). The UE 102(2) might also have other PDU sessions 202for other uses.

At 506, the UE 102(2) may receive user input to activate the PDTS. Insome examples, the user input received at block 506 may correspond tonavigating a browser to a site (e.g., the user entering a URL 114 of thePDTS portal into a web browser, as depicted in FIG. 1 ).

At 508, the UE 102(2) may determine that a URSP rule of the existing(first) set of URSP rules specifies an ID (e.g., an address, FQDN, etc.)of the site to which the user 104(2) pointed the browser. This ID matchat block 508 may indicate that the user 104(2) wishes to activate thePDTS on demand. In this scenario, the user 104(2) may represent a GETSuser 104(2) who may have borrowed the UE 102(2) from someone else (e.g.,a bystander in a public place).

At 510, the URSP rule that specifies the ID of the site at block 508 maytrigger the UE 102(2) to send a PDU session establishment request forthe second (PDTS non-subscriber) network slice (e.g.,S-NSSAI_(PDTS-nonsub)). In some examples, the PDU session establishmentrequest may include a specific DNN_(PDTS-nonsub) and perhaps otherparameters. The second (PDTS non-subscriber) network slice is a prioritynetwork slice for non-subscribers of the PDTS. On the network side, inresponse to the UE 102(2) sending the PDU session establishment request,an AMF may select an appropriate SMF for this new priority PDU session.The selected SMF may perform a PDU session establishment by contactingthe PCF for authorization. The contacted PCF may instruct traffic (e.g.,all traffic) for this intermediate PDU session to be treated with higherpriority compared to regular Internet access, but traffic associatedwith the intermediate PDU session may be limited to that which isdestined for the PDTS portal address (other traffic not destined for thePDTS portal address may still flow on the normal PDU session 202(A)).

At 512, the UE 102(2) may receive, during the intermediate PDU session,second user input corresponding to credentials 116 entered by a user104(2) of the UE 102(2) via the site for authenticating with the PDTS.For example, the GETS user 104(2) may authenticate at the PDTS portal byentering credentials 116 (e.g., username and/or password). Thisauthentication exchange may be carried over the intermediate PDU sessionwith priority. If authentication is unsuccessful at block 512, theintermediate (priority) PDU session may be torn down and no furtheraction is taken. If authentication is successful at block 512, the PDTSportal may act as an Application Function (AF) and use 3GPP 5GStandardized Application Function influence on traffic routing mechanismto deliver priority service policy to the PCF. The PDTS portal maydirectly contact a Network Exposure Function gateway, or it may utilizean intermediate server that performs the AF Influence mechanism onbehalf of the PDTS portal. The PDTS portal may identify the serving UE102(2) using an IP address of the UE 102(2). The AF-Service-Identifiermay be based on the GETS user’s 104(2) username/ID. Based on thereceived priority service policy based on the authenticated GETS user104(2) and internal configuration, the PCF may update access policy tothe AMF to include a third (PDTS) network slice 200(B), S-NSSAI_(PDTS)(even though the UE 102(2) itself has no subscription to the PDTS). ThePCF may instruct the SMF to tear down the intermediate PDU session.

At 514, the PCF may initiate a UE configuration update to replace theexisting URSP rules in the UE 102(2) with a new (second) set of URSPrules 112(2), and the UE 102(2) may, therefore, receive the second setof URSP rules 112(2) to replace the existing (first) set of URSP rulesin the memory of the UE 102(2). The second set of URSP rules 112(2) mayinclude a (default) URSP rule that causes the UE 102(2) to send datapackets during a PDU session 202(B) via the third (PDTS) network slice200(B). For example, the (default) URSP rule may direct traffic (e.g.,all traffic) to the third (PDTS) network slice 200(B) and PDU session202(B), and optionally may include, a specific DNN_(PDTS) and perhapsother parameters. This may include preferred access set to 5G, whichprevents data over WiFi. For example, the (default) URSP rule of thesecond set of URSP rules 112(2) may prevent data packets from being sentover Wi-Fi during the PDU session 202(B). The second set of URSP rules112(2) may further include URSP rule at the highest precedence withS-NSSAI_(PDTS-turn-off), and optionally, a specific DNN_(PDTS-turn-off)and perhaps other parameters and traffic description matching the PDTSportal address or FQDN. In some examples, the first PDU session 202(A)may be maintained (e.g., with no traffic). In other examples, the firstPDU session 202(A) may be torn down.

At 516, the UE 102(2) may send (and receive) one or more data packetsduring a PDU session 202(B) via the third (PDTS) network slice 200(B).That is, if the user 104(2) provides user input to access the Internet,for example, the UE 102(2) may utilize the third (PDTS) network slice200(B) based on the (default) URSP rule of the second set of URSP rules112(2) received by the UE 102(2) at block 514. In some examples, the UE102(2) may send, at block 516, a PDU session establishment request forslice S-NSSAI_(PDTS) with optionally, a specific DNN_(PDTS) and perhapsother parameters. The PDU session establishment results in a new PDUsession 202(B) in the third (PDTS) network slice 200(B) to beestablished by SMF. Based on the received priority policy from the PDTSportal and internal configuration, the PCF may instruct traffic (e.g.,all traffic) for this new PDU session 202(B) to be treated with higherpriority compared to regular Internet access, thereby reducing the riskof pre-emption during a period of traffic congestion. This includesadjusting QoS parameters for priority and ARP as per standards forpriority data service. Accordingly, Internet traffic (e.g., all Internettraffic) runs over the PDU session 202(B) using the third (PDTS) networkslice 200(B) (e.g., slice S-NSSAI_(PDTS)). The settings of this PDUsession 202(B) may be such that traffic (e.g., all traffic) is sent overa QoS enabled flow with high priority across both the RAN network andthe core network 106.

At 518, the UE 102(2) may receive second user input to deactivate thePDTS. In some examples, the user input received at block 518 maycorrespond to navigating a browser to a site (e.g., the user enteringthe URL 114 of the PDTS portal into a web browser). The user 104(2) maynot enter anything into the portal to deactivate the PDTS (e.g.,navigating the browser to the site may be sufficient for deactivation ofthe PDTS).

At 520, the UE 102(2) may determine that a URSP rule of the received(second) set of URSP rules 112(2) specifies an ID (e.g., an address,FQDN, etc.) of the site to which the user 104(1) pointed the browser.This ID match at block 520 may indicate that the user 104(2) wishes todeactivate the PDTS on demand.

At 522, the URSP rule (of the second set of URSP rules 112(2)) at thehighest precedence with S-NSSAI_(PDTS-turn-off) may trigger the UE102(2) to send a PDU session establishment request for sliceS-NSSAI_(PDTS-turn-off) with optionally, a specific DNN_(PDTS-turn-)_(off) and perhaps other parameters. On the network side, the PDUsession establishment request sent at block 522 may trigger the AMF toselect the same SMF for this new PDU session 200(A) as the current SMF.The SMF may perform a PDU session establishment by contacting the PCFfor authorization. The PCF may approve the PDU session establishment (toallow some user interaction at the portal, such as a logoffconfirmation). However, based on the PDTS-turn-off session slice, thePCF may initiate a UE configuration update to replace the existing(second) set of URSP rules 112(2) in the UE 102(2) with the original(first) set of URSP rules before PDTS service activation.

Accordingly, at 524, based on the UE configuration update initiated bythe PCF, the UE 102(2) may receive the original (first) set of URSPrules to replace the second set of URSP rules 112(2) in the memory ofthe UE 102(2). As shown in FIG. 5 , the process 500 may return to block504 following block 524 to iterate blocks 504-524 as the user 104(2)toggles the PDTS ON and OFF, in an on demand fashion. In other words,following block 524, the UE 102(2) may, at block 504, send (and receive)one or more data packets during a PDU session 202(A) via the first(eMBB) network slice 200(A) (e.g., S-NSSAI_(eMBB)). That is, if the user104(2) provides user input to access the Internet, for example, the UE102(2) may utilize the first (eMBB) network slice 200(A) based on the(default) URSP rule of the original (first) set of URSP rules receivedby the UE 102(2) at block 524. For example, the (default) URSP rule ofthe original (first) set of URSP rules may trigger the UE 102(2) to senda PDU session establishment request for the first (eMBB) network slice200(A) (e.g., S-NSSAI_(eMBB)) for regular Internet access per theupdated URSP rules, where Internet traffic (e.g., all Internet traffic)runs over the PDU session 202(A) using the first (eMBB) network slice200(A) (e.g., S-NSSAI_(eMBB)). If the previous PDU session 202(A) wasnot torn down, the UE 102(1) may send traffic over the first (eMBB)network slice 200(A), and the UE 102(1) may refrain from establishing anew PDU session, in this example. The PCF may provide the SMF with theoriginal set of PCC rules for various QoS flows to be used by the UE102(2) for non-priority services. It is to be appreciated, however, thatthe UE 102(2) may have other PDU sessions 202 for other uses.Furthermore, any traffic routing instructions for these PDU sessions 202may be restored to their original state before the PDTS activation.

FIGS. 6A-6C illustrate a flowchart of an example process 600 to beimplemented by a network node(s) for activating the PDTS for a UE 102,according to various embodiments. The process 600 is described withreference to the previous figures.

At 602 of FIG. 6A, a network node of a telecommunication network mayreceive, from a UE 102, a request to register the UE for multiplenetwork slices 200. In an illustrative example, the network node mayreceive in the requested NSSAI: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)} or{S-NSSAI_(PDTS-nonsub), S-NSSAI_(eMBB)}.

At 604, the network node may determine whether one of the multiplenetwork slices 200 is a PDTS network slice 200(B) (e.g.,S-NSSAI_(PDTS)). If the PDTS network slice 200(B) is not included in theregistration request (e.g., if the network node receives in therequested NSSAI: {S-NSSAI_(PDTS-nonsub), S-NSSAI_(eMBB)}), the process600 may follow the NO route from block 604 to block 606, where thenetwork node (or a different network node of the telecommunicationnetwork) may register the UE 102 for the requested network slices 200,which may include a first (eMBB) network slice 200(A) and a second (PDTSnon-subscriber) network slice, the second (PDTS non-subscriber) networkslice being usable by UEs 102 that are not subscribed to the PDTS toactivate the PDTS.

If, at 604, the PDTS network slice 200(B) is included in theregistration request (e.g., if the network node receives in therequested NSSAI: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)}), the process 600 mayfollow the YES route from block 604 to block 608, where the network node(or a different network node of the telecommunication network) maydetermine whether the UE’s 102 subscription has PDTS network slicesupport.

At 608, if the network node determines that the UE’s 102 subscriptiondoes not have PDTS network slice support, the process 600 may follow theNO route from block 608 to block 606, where the network node (or adifferent network node of the telecommunication network) may registerthe UE 102 for the first (eMBB) network slice 200(A) and a second (PDTSnon-subscriber) network slice because the UE’s 102 subscription does nothave PDTS network slice support. At 608, if the network node determinesthat the UE’s 102 subscription has PDTS network slice support, theprocess 600 may follow the YES route from block 608 to block 610, wherethe network node (or a different network node of the telecommunicationnetwork) may register the UE 102 for the requested network slices 200,which may include a first (eMBB) network slice 200(A) and a second(PDTS) network slice 200(B), the second (PDTS) network slice 200(B). Forexample, the network node may confirm that the UE’s 102 subscription hasPDTS slice support, and, if so, may return, to the UE 102, an AllowedNSSAI set that includes the PDTS network slice 200(B) and other networkslices, such as the eMBB network slice 200(A). For example, AllowedNSSAI may include: {S-NSSAI_(PDTS), S-NSSAI_(eMBB)}. This confirmationobtained by the network node(s) at block 608 provides a first levelcheck for PDTS service. The UE 102 may be considered “registered” forthe multiple network slices 200 at block 606 or 610, but an individualnetwork slice 200 is not activated until a PDU session is established.

Turning to FIG. 6B, the process 600 may continue from block 610 of FIG.6A, as indicated by the off-page reference “A” in FIGS. 6A and 6B. At612, a network node may receive, from the UE 102, a PDU sessionestablishment request via the first (eMBB) network slice 200(A). Forexample, the user 104 of the UE 102 may have provided user input to theUE 102 causing the UE 102 to send data, and the UE 102 may have sent thePDU session establishment request received at block 612 usingS-NSSAI_(eMBB) for regular Internet access. The request received atblock 612 might include other PDU session parameters such as DNN_(eMBB).

At 614, a network node may route one or more data packets associatedwith a PDU session 202(A) involving the UE 102 via the first (eMBB)network slice 200(A). Accordingly, Internet traffic (e.g., all Internettraffic) runs over the PDU session 202(A) using the first (eMBB) networkslice 200(A) (i.e., S-NSSAI_(eMBB)).

At 616, a network node may receive, from the UE 102, a PDU sessionestablishment request via the PDTS network slice 200(B) (e.g.,S-NSSAI_(PDTS)). In some examples, the PDU session establishment requestreceived at block 616 may include a specific DNN_(PDTS) and perhapsother parameters. The PDTS network slice 200(B) is a priority networkslice. In some examples, in response to receiving the PDU sessionestablishment request at block 616, an AMF may select an appropriate SMFat block 618 for this new priority PDU session 202(B). The selected SMFmay perform a PDU session establishment by contacting the PCF forauthorization at block 620. The contacted PCF may, at block 622,instruct traffic (e.g., all traffic) for this PDU session 202(B) to betreated with higher priority compared to regular Internet access,thereby reducing the risk of pre-emption during a period of trafficcongestion. The PCF supports adjusting QoS parameters for priority andARP, as per standards for priority data service.

At 624, a network node may perform secondary slice authentication toactivate the PDTS based on credentials received from the UE 102. Asnoted above, secondary slice authentication is optional and may beomitted from the process 600. The secondary slice authenticationperformed at block 624 may run EAP between the UE 102 and an AAA server,as indicated by sub-block 626. The AAA server may be operated by themobile operator on behalf of an authenticating agency, or the AAA servermay be operated by the authenticating agency and may perform anauthentication dedicated to the PDTS. This secondary AAA server providesan additional check that the UE 102 identity is valid and authorized forthe PDTS through a set of credentials dedicated to the PDTS that arealready provisioned on the UE 102.

At 628, a network node (e.g., the PCF) may initiate a UE configurationupdate (e.g., to replace the existing URSP rules in the UE 102(1)) witha new (second) set of URSP rules 112(1), and the network node (e.g., thePCF) may, therefore, send (e.g., download) to the UE 102 a new (second)set of URSP rules 112(1) (e.g., to replace the existing (first) set ofURSP rules in the memory of the UE 102). The second set of URSP rules112(1) may include a (default) URSP rule that causes the UE 102 to senddata packets during a PDU session 202(B) via the PDTS network slice200(B). For example, the (default) URSP rule may direct traffic (e.g.,all traffic) to the second (PDTS) network slice 200(B) and PDU session202(B). This may include preferred access set to 5G, which prevents dataover WiFi. For example, the (default) URSP rule of the second set ofURSP rules 112(1) may prevent data packets from being sent over Wi-Fiduring the PDU session 202(B). The second set of URSP rules 112(1) mayfurther include URSP rule at the highest precedence withS-NSSAI_(PDTS-turn-off), and optionally, a specific DNN_(PDTS-turn-off)and perhaps other parameters and traffic description matching: (i) thePDTS portal address or FQDN, or (ii) an app ID for a PDTS app on the UE102. In some examples, the first PDU session 202(A) may be maintained(e.g., with no traffic). In other examples, the first PDU session 202(A)may be torn down.

Accordingly, at 630, a network node may route one or more data packetsassociated with a PDU session 202(B) involving the UE 102 via the PDTSnetwork slice 200(B). For example, if the user 104 of the UE 102provides user input to access the Internet, the UE 102 may utilize thePDTS network slice 200(B) based on the (default) URSP rule of the secondset of URSP rules 112(1) sent (e.g., downloaded) to the UE 102 at block628. Accordingly, Internet traffic (e.g., all Internet traffic) runsover the PDU session 202(B) using the PDTS network slice 200(B) (e.g.,slice S-NSSAI_(PDTS)). The settings of this PDU session 202(B) may besuch that traffic (e.g., all traffic) is sent over a QoS enabled flowwith high priority across both the RAN network and the core network 106.

At 632, a network node may receive, from the UE 102, a PDU sessionestablishment request for slice S-NSSAI_(PDTS-turn-off) with optionally,a specific DNN_(PDTS-turn-) _(off) and perhaps other parameters. Asnoted above, the network slice for S-NSSAI_(PDTs-turn-off) may befunctionally equivalent to the PDTS network slice 200(B) (e.g.,S-NSSAI_(PDTS)), but the network slice for S-NSSAI_(PDTS-turn-off) maybe associated with a different S-NSSAI value than the PDTS network slice200(B). The PDU session establishment request received at block 632 maytrigger the AMF to select, at block 634 the same SMF for this new PDUsession 200(A) as the current SMF. The SMF may perform a PDU sessionestablishment by contacting the PCF for authorization at block 636. ThePCF may, at block 638, approve the PDU session establishment (to allowsome user interaction at the portal, such as a logoff confirmation).

At 640, based on the PDTS-turn-off session slice, a network node (e.g.,the PCF) may initiate a UE configuration update (e.g., to replace theexisting (second) set of URSP rules 112(1) in the UE 102 with theoriginal (first) set of URSP rules that were used before PDTS serviceactivation), and, therefore, the network node (e.g., the PCF via theAMF), at block 640, may send (e.g., download) to the UE 102 the original(first) set of URSP rules to replace the second set of URSP rules 112(1)in the memory of the UE 102. If the original (first) set of URSP ruleswere retained in the memory of the UE 102 at a time of downloading thesecond set of URSP rules 112(1), then the network node may not send theUE 102 any new URSP rules. As shown in FIG. 6B, the process 600 mayreturn to block 612 following block 640 to iterate blocks 612-640 as theuser 104 toggles the PDTS ON and OFF, in an on demand fashion. Forexample, the (default) URSP rule of the original (first) set of URSPrules may trigger the UE 102 to send, and the network node may thereforereceive, a PDU session establishment request at block 612 for the first(eMBB) network slice 200(A) (e.g., S-NSSAI_(eMBB)) for regular Internetaccess per the updated URSP rules. At 614, Internet traffic (e.g., allInternet traffic) is routed over the PDU session 202(A) using the first(eMBB) network slice 200(A) (e.g., S-NSSAI_(eMBB)). It is to beappreciated that, if the previous PDU session 202(A) was not torn down,traffic may be routed over the first (eMBB) network slice 200(A), andthe process 600 may proceed from block 640 directly to block 614,without establishing a new PDU session. Further, the PCF may provide theSMF with the original set of PCC rules for various QoS flows to be usedby the UE 102 for non-priority services. It is to be appreciated,however, that the UE 102 may have other PDU sessions 202 for other uses.Furthermore, any traffic routing instructions for these PDU sessions 202may be restored to their original state before the PDTS activation.

Turning to FIG. 6C, the process 600 may continue from block 606 of FIG.6A, as indicated by the off-page reference “B” in FIGS. 6A and 6C. At642, a network node may receive, from the UE 102, a PDU sessionestablishment request via the first (eMBB) network slice 200(A). Forexample, the user 104 of the UE 102 may have provided user input to theUE 102 causing the UE 102 to send data, and the UE 102 may have sent thePDU session establishment request received at block 642 usingS-NSSAI_(eMBB) for regular Internet access. The request received atblock 642 might include other PDU session parameters such as DNN_(eMBB).

At 644, a network node may route one or more data packets associatedwith a PDU session 202(A) involving the UE 102 via the first (eMBB)network slice 200(A). Accordingly, Internet traffic (e.g., all Internettraffic) runs over the PDU session 202(A) using the first (eMBB) networkslice 200(A) (i.e., S-NSSAI_(eMBB)).

At 646, a network node may receive, from the UE 102, a PDU sessionestablishment request via the PDTS non-subscriber network slice (e.g.,S-NSSAI_(PDTS-nonsub)). In some examples, the PDU session establishmentrequest received at block 646 may include a specific DNN_(PDTS-nonsub)and perhaps other parameters. The PDTS non-subscriber network slice is apriority network slice for non-subscribers of the PDTS. In someexamples, receiving the PDU session establishment request at block 646,an AMF may select an appropriate SMF at block 648 for this new priorityPDU session. The selected SMF may perform a PDU session establishment bycontacting the PCF for authorization at block 650. The contacted PCFmay, at block 652, instruct traffic (e.g., all traffic) for thisintermediate PDU session to be treated with higher priority compared toregular Internet access, but traffic associated with the intermediatePDU session may be limited to that which is destined for the PDTS portaladdress (other traffic not destined for the PDTS portal address maystill flow on the normal PDU session 202(A)).

At 654, a network node may authenticate credentials 116 entered by auser 104 of the UE 102 via the site (e.g., the PDTS portal) during theintermediate PDU session for authenticating with the PDTS. For example,the GETS user 104(2) may authenticate at the PDTS portal by enteringcredentials 116 (e.g., username and/or password). This authenticationexchange may be carried over the intermediate PDU session with priority.If authentication is unsuccessful at block 654, the intermediate(priority) PDU session may be torn down and no further action is taken.If authentication is successful at block 654, the PDTS portal may, atsub-block 656, act as an AF and use 3GPP 5G Standardized ApplicationFunction influence on traffic routing mechanism to deliver priorityservice policy to the PCF. The PDTS portal may directly contact aNetwork Exposure Function gateway, or it may utilize an intermediateserver that performs the AF Influence mechanism on behalf of the PDTSportal. The PDTS portal may identify the serving UE 102 using an IPaddress of the UE 102. The AF-Service-Identifier may be based on theGETS user’s 104(2) username/ID.

At 658, based on the received priority service policy based on theauthenticated GETS user 104(2) and internal configuration, the networknode may authorize the UE 102 for access to the PDTS network slice200(B). For example, the PCF may update access policy to the AMF toinclude a third (PDTS) network slice 200(B), S-NSSAI_(PDTS) (even thoughthe UE 102 itself has no subscription to the PDTS). The PCF may instructthe SMF to tear down the intermediate PDU session.

At 660, a network node (e.g., the PCF) may initiate a UE configurationupdate (e.g., to replace the existing URSP rules in the UE 102 with anew (second) set of URSP rules 112(2)), and the network node (e.g., thePCF) may, therefore, send (e.g., download) to the UE 102 the second setof URSP rules 112(2) to replace the existing (first) set of URSP rulesin the memory of the UE 102. The second set of URSP rules 112(2) mayinclude a (default) URSP rule that causes the UE 102 to send datapackets during a PDU session 202(B) via the PDTS network slice 200(B).For example, the (default) URSP rule may direct traffic (e.g., alltraffic) to the PDTS network slice 200(B) and PDU session 202(B), andoptionally may include, a specific DNN_(PDTS) and perhaps otherparameters. This may include preferred access set to 5G, which preventsdata over WiFi. For example, the (default) URSP rule of the second setof URSP rules 112(2) may prevent data packets from being sent over Wi-Fiduring the PDU session 202(B). The second set of URSP rules 112(2) mayfurther include URSP rule at the highest precedence withS-NSSAI_(PDTS-turn-off), and optionally, a specific DNN_(PDTS-turn-off)and perhaps other parameters and traffic description matching the PDTSportal address or FQDN. In some examples, the first PDU session 202(A)may be maintained (e.g., with no traffic). In other examples, the firstPDU session 202(A) may be torn down.

At 662, a network node may route one or more data packets during a PDUsession 202(B) via the third (PDTS) network slice 200(B). That is, ifthe user 104 provides user input to access the Internet, for example,the UE 102 may utilize the third (PDTS) network slice 200(B) based onthe (default) URSP rule of the second set of URSP rules 112(2) sent(e.g., downloaded) to the UE 102 at block 660. In some examples, thenetwork node may receive, at sub-block 664, a PDU session establishmentrequest for slice S-NSSAI_(PDTS) with optionally, a specific DNN_(PDTS)and perhaps other parameters. The PDU session establishment results in anew PDU session 202(B) in the third (PDTS) network slice 200(B) to beestablished by SMF. Based on the received priority policy from the PDTSportal and internal configuration, the PCF may, at block 666, instructtraffic (e.g., all traffic) for this new PDU session 202(B) to betreated with higher priority compared to regular Internet access,thereby reducing the risk of pre-emption during a period of trafficcongestion. This includes adjusting QoS parameters for priority and ARPas per standards for priority data service. Accordingly, Internettraffic (e.g., all Internet traffic) is routed over the PDU session202(B) using the third (PDTS) network slice 200(B) (e.g., sliceS-NSSAI_(PDTS)). The settings of this PDU session 202(B) may be suchthat traffic (e.g., all traffic) is sent over a QoS enabled flow withhigh priority across both the RAN network and the core network 106.

At 668, a network node may receive, from the UE 102, a PDU sessionestablishment request for slice S-NSSAI_(PDTS-turn-off) with optionally,a specific DNN_(PDTS-turn-) _(off) and perhaps other parameters. The PDUsession establishment request received at block 668 may trigger the AMFto select, at block 670 the same SMF for this new PDU session 200(A) asthe current SMF. The SMF may perform a PDU session establishment bycontacting the PCF for authorization at block 672. The PCF may, at block674, approve the PDU session establishment (to allow some userinteraction at the portal, such as a logoff confirmation).

At 676, based on the PDTS-turn-off session slice, a network node (e.g.,the PCF) may initiate a UE configuration update (e.g., to replace theexisting (second) set of URSP rules 112(2) in the UE 102 with theoriginal (first) set of URSP rules that were used before PDTS serviceactivation), and, therefore, the network node (e.g., the PCF), at block676, may send (e.g., download) to the UE 102 the original (first) set ofURSP rules to replace the second set of URSP rules 112(2) in the memoryof the UE 102. If the original (first) set of URSP rules were retainedin the memory of the UE 102 at a time of downloading the second set ofURSP rules 112(2), the network node may not send the UE 102 any new URSPrules. As shown in FIG. 6C, the process 600 may return to block 642following block 676 to iterate blocks 642-676 as the user 104 togglesthe PDTS ON and OFF, in an on demand fashion. For example, the (default)URSP rule of the original (first) set of URSP rules may trigger the UE102 to send, and the network node may therefore receive, a PDU sessionestablishment request at block 642 for the first (eMBB) network slice200(A) (e.g., S-NSSAI_(eMBB)) for regular Internet access per theupdated URSP rules. At 644, Internet traffic (e.g., all Internettraffic) is routed over the PDU session 202(A) using the first (eMBB)network slice 200(A) (e.g., S-NSSAI_(eMBB)). It is to be appreciatedthat, if the previous PDU session 202(A) was not torn down, traffic maybe routed over the first (eMBB) network slice 200(A), and the process600 may proceed from block 676 directly to block 644, withoutestablishing a new PDU session. Further, the PCF may provide the SMFwith the original set of PCC rules for various QoS flows to be used bythe UE 102 for non-priority services. It is to be appreciated, however,that the UE 102 may have other PDU sessions 202 for other uses.Furthermore, any traffic routing instructions for these PDU sessions 202may be restored to their original state before the PDTS activation.

Yet another example technique for implementing the PDTS is to use athird party (3P) Application Server, without network slicing and withoutURSP rules. This technique does not prioritize the initial period toestablish PDTS user authorization and authentication, it offers apotentially stronger authentication mechanism than that which isavailable from AAA protocols, and it does not have URSP rules for PDTSnetwork slices resident in the UE 102, which may mitigate some securitythreats/risks.

In this alternative technique for implementing the PDTS, a UE 102 mayestablish a PDU session 202(A) for regular Internet access, wherebyInternet traffic runs over the PDU session 202(A) without priority. Atsome point, a (WPS/GETS) user 104 of the UE 102 wishes to activate thePDTS. The (WPS/GETS) user 104 may point a browser executing on the UE102 at the PDTS portal address or FQDN, and the user 104 mayauthenticate at the PDTS portal (e.g., by entering credentials 116, suchas a username and password). This authentication exchange is carriedover the regular PDU session 202(A).

If authentication is unsuccessful, no further action is taken. Uponsuccessful authentication, the portal acts as an AF and uses 3GPP 5GStandardized Application Function influence on traffic routing mechanismto deliver priority service policy to the PCF. The PDTS portal maydirectly contact a Network Exposure Function gateway or go through anintermediate server that performs the AF Influence mechanism on behalfof the PDTS portal. The PDTS portal may identify the serving UE 102using its IP address. The AF-Service-Identifier may be based on theWPS/GETS user’s 104 username/ID.

Based on the received priority service policy and internalconfiguration, the PCF may update the QoS parameters that apply to thegeneral Internet PDU session 202(A). The SMF may receive updated PCCrules and take appropriate action (as per standards). Thereafter,traffic (e.g., all traffic) for this PDU session is treated with higherpriority compared to regular Internet access, thereby reducing the riskof pre-emption during period of traffic congestion. Alternatively,another new PDU session 202(B) may be established with the proper QoSparameters and other PDU session parameters and the old PDU session202(A) released. Again, traffic (e.g., all traffic) for this new PDUsession 202(B) is treated with higher priority compared to regularInternet access, thereby reducing the risk of pre-emption during periodof traffic congestion.

At some point, a (WPS/GETS) user 104 may wish to deactivate the PDTS.The (WPS/GETS) user 104 may point the browser at the PDTS portal addressor FQDN. The (WPS/GETS) user 104 may indicate deactivation to the PDTSportal with little-to-no security. This exchange may be carried over thepriority PDU session 202(B). The PDTS portal may act as an AF and use3GPP 5G Standardized Application Function influence on traffic routingmechanism to deliver priority service policy to the PCF. The portal maydirectly contact a Network Exposure Function gateway or go through anintermediate server that performs the AF Influence mechanism on behalfof the PDTS portal. The PDTS portal may identify the serving UE 102using its IP address. The AF-Service-Identifier may be based on the(WPS/GETS) user’s 104 username/ID.

Based on the received service policy and internal configuration, the PCFmay update the QoS parameters that apply to the general Internet PDUsession 202(A). The SMF may receive updated PCC rules and takeappropriate action (as per standards). Thereafter, traffic (e.g., alltraffic) for this PDU session 202(A) is treated with normal priority.Alternatively, another new PDU session 202(A) may be established withthe normal (non-priority) QoS parameters and other PDU sessionparameters, and the previous, priority PDU session 202(B) released.

FIG. 7 is a block diagram of an example UE 102 with logic toactivate/deactivate the PDTS, according to various embodiments. Asshown, the UE 102 may include one or more processors 702 and one or moreforms of computer-readable memory 704. The UE 102 may also includeadditional storage devices. Such additional storage may includeremovable storage 706 and/or non-removable storage 708.

The UE 102 may further include input devices 710 (e.g., a touch screen,keypad, keyboard, mouse, pointer, microphone, etc.) and output devices712 (e.g., a display, printer, speaker, etc.) communicatively coupled tothe processor(s) 702 and the computer-readable memory 704. The UE 102may further include communications interface(s) 714 that allow the UE102 to communicate with other computing devices 716 (e.g., networknodes, other UEs, etc.) such as via a network. The communicationsinterface(s) 714 may facilitate transmitting and receiving wired and/orwireless signals over any suitable communications/data technology,standard, or protocol, as described herein. For example, thecommunications interface(s) 714 can comprise a wired interface and/orone or more of a cellular radio, a wireless (e.g., IEEE 802. 1x-based)interface, a Bluetooth® interface, and so on.

In various embodiments, the computer-readable memory 704 comprisesnon-transitory computer-readable memory 704 that generally includes bothvolatile memory and non-volatile memory (e.g., random access memory(RAM), read-only memory (ROM), erasable programmable read-only memory(EEPROM), Flash Memory, miniature hard drive, memory card, opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium). Thecomputer-readable memory 704 may also be described as computer storagemedia and may include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data. Computer-readable memory 704, removablestorage 706 and non-removable storage 708 are all examples ofnon-transitory computer-readable storage media. Computer-readablestorage media include, but are not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, compact disc read-only memory(CD-ROM), digital versatile disks (DVD) or other optical storage,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, or any other medium which can be used to storethe desired information and which can be accessed by the UE 102. Anysuch computer-readable storage media may be part of the UE 102.

The memory 704 can include a PDTS module 718 (i.e., computer-executableinstructions (or logic) that, when executed, by the processor(s) 702,perform the various acts and/or processes disclosed herein. For example,the PDTS module 718 is configured to carry out the activation,utilization, and deactivation of the PDTS, as described herein. Thememory 704 can further be used to store URSP rules 720, which mayrepresent existing URSP rules 720 of the UE 102, and which may bereplaced by new URSP rules 112, as described herein.

FIG. 8 is a block diagram of an example network node(s) 800 with logicto activate/deactivate the PDTS for one or more UEs, according tovarious embodiments. The network node(s) 800 may be representative of anetwork node(s) of the core network 106, and/or a network node(s) of a5G system, and the network node(s) 800 may be configured to perform theoperations of the example process 600 described herein.

As shown, the network node(s) 800 may include one or more processors 802and one or more forms of computer-readable memory 804. The networknode(s) 800 may also include additional storage devices. Such additionalstorage may include removable storage 806 and/or non-removable storage808. The memory 804, the removable storage 806, and the non-removablestorage 808 may be implemented similarly to the memory 704, removablestorage 706, and non-removable storage 708 described above withreference to FIG. 7 , and will not be described further for the sake ofbrevity.

The network node(s) 800 may further include input devices 810, outputdevices 812, and communications interface(s) 814 for communicating withother computing devices 816. These too may be implemented similarly tothe input devices 710, output devices 712, and communicationsinterface(s) 714 described above with reference to FIG. 7 , and will notbe described further for the sake of brevity.

The memory 804 can include a PDTS module 818 (i.e., computer-executableinstructions (or logic) that, when executed, by the processor(s) 802,perform the various acts and/or processes disclosed herein. For example,the PDTS module 818 is configured to carry out the activation,implementation, and deactivation of the PDTS on behalf of UEs 102, asdescribed herein. The memory 804 can further be used to store URSP rules820, which may represent, for example, URSP rules 112 to replaceexisting URSP rules on UEs 102, as described herein

The environment and individual elements described herein may of courseinclude many other logical, programmatic, and physical components, ofwhich those shown in the accompanying figures are merely examples thatare related to the discussion herein.

The various techniques described herein are assumed in the givenexamples to be implemented in the general context of computer-executableinstructions or software, such as program modules, that are stored incomputer-readable storage and executed by the processor(s) of one ormore computers or other devices such as those illustrated in thefigures. Generally, program modules include routines, programs, objects,components, data structures, etc., and define operating logic forperforming particular tasks or implement particular abstract data types.

Other architectures may be used to implement the describedfunctionality, and are intended to be within the scope of thisdisclosure. Furthermore, although specific distributions ofresponsibilities are defined above for purposes of discussion, thevarious functions and responsibilities might be distributed and dividedin different ways, depending on circumstances.

Similarly, software may be stored and distributed in various ways andusing different means, and the particular software storage and executionconfigurations described above may be varied in many different ways.Thus, software implementing the techniques described above may bedistributed on various types of computer-readable media, not limited tothe forms of memory that are specifically described.

We claim:
 1. (canceled)
 2. A user equipment (UE) comprising: a processor; and memory storing a set of UE route selection policy (URSP) rules and computer-executable instructions that, when executed by the processor, cause the UE to: register for a first network slice and a second network slice, wherein the second network slice is configured to provide higher priority transport of data packets during protocol data unit (PDU) sessions than the first network slice; and based on the set of URSP rules: when using a priority data transport service (PDTS), send data packets via the second network slice, and when not using the PDTS, send data packets via the first network slice.
 3. The UE of claim 2, wherein the computer-executable instructions, when executed by the processor, further cause the UE to: receive user input to activate the PDTS, wherein the user input corresponds to at least one of navigating a browser to a site or launching an application; and determine that a URSP rule of the set of URSP rules specifies an identifier (ID) of at least one of the site or the application.
 4. The UE of claim 2, wherein the computer-executable instructions, when executed by the processor, further cause the UE to: receive a second set of URSP rules, wherein the set of URSP rules is a first set of URSP rules; delete the first set of URSP rules from the memory at a time of receiving the second set of URSP rules; receive user input to deactivate the PDTS; send a PDU session establishment request; receive, based at least in part on the PDU session establishment request, the first set of URSP rules to replace the second set of URSP rules in the memory; and send, based at least in part on a URSP rule of the first set of URSP rules, one or more second data packets during a second PDU session via the first network slice.
 5. The UE of claim 2, wherein a URSP rule of the set of URSP rules prevents one or more data packets from being sent over Wi-Fi during a PDU session.
 6. The UE of claim 2, wherein: the UE is subscribed to the PDTS; the second network slice is usable by UEs that are subscribed to the PDTS to activate and use the PDTS; and one or more data packets are sent during a PDU session via the second network slice.
 7. The UE of claim 6, wherein the computer-executable instructions, when executed by the processor, further cause the UE to, prior to receiving a second set of URSP rules, send credentials for authenticating with the PDTS.
 8. The UE of claim 2, wherein: the UE is not subscribed to the PDTS; the second network slice is usable by UEs that are not subscribed to the PDTS to activate the PDTS; the computer-executable instructions, when executed by the processor, further cause the UE to, prior to receiving a second set of URSP rules: receive user input to activate the PDTS, wherein the user input corresponds to navigating a browser to a site send, based at least in part on a URSP rule of the set of URSP rules, a PDU session establishment request via the second network slice; and receive, during an intermediate PDU session, second user input corresponding to credentials entered by a user of the UE via the site; and one or more data packets are sent during a PDU session via a third network slice that is configured to provide higher priority transport of data packets during PDU sessions than the first network slice.
 9. A method comprising: registering, by a user equipment (UE), for a first network slice and a second network slice, wherein the second network slice is configured to provide higher priority transport of data packets during protocol data unit (PDU) sessions than the first network slice; based on a set of UE Route Selection Policy (URSP) rules: when using a priority data transport service (PDTS), sending, by the UE, data packets via the second network slice, and when not using the PDTS, sending, by the UE, data packets via the first network slice.
 10. The method of claim 9, wherein: the set of URSP rules comprises a second set of URSP rules; and the method further comprises: receiving user input to activate the PDTS, wherein the user input corresponds to at least one of navigating a browser to a site or launching an application; and prior to the receiving of the second set of URSP rules, determining that a URSP rule of a first set of URSP rules stored in memory of the UE specifies an identifier (ID) of at least one of the site or the application.
 11. The method of claim 9, wherein the set of URSP rules comprises a second set of URSP rules, the method further comprising: deleting a first set of URSP rules from memory of the UE at a time of receiving of the second set of URSP rules receiving user input to deactivate the PDTS; sending, by the UE, a PDU session establishment request; receiving, based at least in part on the PDU session establishment request, the first set of URSP rules to replace the second set of URSP rules in the memory; and sending, based at least in part on a URSP rule of the first set of URSP rules, one or more data packets during a PDU session via the first network slice.
 12. The method of claim 9, wherein a URSP rule of the set of URSP rules prevents one or more data packets from being sent over Wi-Fi during a PDU session.
 13. The method of claim 9, wherein: the UE is subscribed to the PDTS; the second network slice is usable by UEs that are subscribed to the PDTS to activate and use the PDTS; and one or more data packets are sent during a PDU session via the second network slice.
 14. The method of claim 13, further comprising, prior to receiving of the set of URSP rules, sending credentials for authenticating with the PDTS.
 15. The method of claim 9, wherein: the set of URSP rules comprises a second set of URSP rules; the UE is not subscribed to the PDTS; the second network slice is usable by UEs that are not subscribed to the PDTS to activate the PDTS; a user input received by the UE corresponds to navigating a browser to a site; the method further comprises, prior to the receiving of the second set of URSP rules: sending, based at least in part on a URSP rule of a first set of URSP rules stored in memory of the UE, a PDU session establishment request via the second network slice; and receiving, during an intermediate PDU session, second user input corresponding to credentials entered by a user of the UE via the site; and one or more data packets are sent during a PDU session via a third network slice.
 16. A non-transitory computer storage medium having a plurality of programming instructions stored thereon that, when executed by a user equipment (UE), cause the UE to perform operations comprising: registering for a first network slice and a second network slice, wherein the second network slice is configured to provide higher priority transport of data packets during protocol data unit (PDU) sessions than the first network slice; based on a set of UE Route Selection Policy (URSP) rules: when using a priority data transport service (PDTS), sending data packets via the second network slice, and when not using the PDTS, sending data packets via the first network slice.
 17. The non-transitory computer storage medium of claim 16, wherein: the set of URSP rules comprises a second set of URSP rules; and the operations further comprise: receiving user input to activate the PDTS, wherein the user input corresponds to at least one of navigating a browser to a site or launching an application; and prior to the receiving of the second set of URSP rules, determining that a URSP rule of a first set of URSP rules stored in memory of the UE specifies an identifier (ID) of at least one of the site or the application.
 18. The non-transitory computer storage medium of claim 16, wherein the set of URSP rules comprises a second set of URSP rules, the operations further comprising: deleting a first set of URSP rules from memory of the UE at a time of receiving of the second set of URSP rules receiving user input to deactivate the PDTS; sending, by the UE, a PDU session establishment request; receiving, based at least in part on the PDU session establishment request, the first set of URSP rules to replace the second set of URSP rules in the memory; and sending, based at least in part on a URSP rule of the first set of URSP rules, one or more data packets during a PDU session via the first network slice.
 19. The non-transitory computer storage medium of claim 16, wherein a URSP rule of the set of URSP rules prevents one or more data packets from being sent over Wi-Fi during a PDU session.
 20. The non-transitory computer storage medium of claim 16, wherein: the UE is subscribed to the PDTS; the second network slice is usable by UEs that are subscribed to the PDTS to activate and use the PDTS; and one or more data packets are sent during a PDU session via the second network slice.
 21. The non-transitory computer storage medium of claim 20, wherein the operations further comprise, prior to receiving of the set of URSP rules, sending credentials for authenticating with the PDTS. 